
=======================================================================
			MICROSOFT FOUNDATION CLASSES 2.52 - SOURCE CODE
=======================================================================

This directory contains the source code to the MFC library.

These files have been included for reference purposes.

These files are compiled to form the Microsoft Foundation Classes 2.52
(MFC 2.52).  The library may be built in a number of configurations, 
depending upon operating system, memory usage or model, and whether 
or not debugging and diagnostic aids are to be included in 
applications which link with the library.


===========================================
 1.  BUILDING A STATIC LINK LIBRARY VARIANT
===========================================

The makefile provided can be used to build the static link library
variants of MFC 2.52.  See section 2 for instructions on building
the shared DLL variant.  The makefile can be used from a command
line environment using the WATCOM WMAKE tool.

To build a library in a particular configuration, use the WMAKE tool
and the Makefile which is in this directory.  The following arguments
can be given to WMAKE to successfully build a specific library variant.

  WMAKE {MODEL=[L]} {TARGET=[W|R]} {DEBUG=[0|1]} {SYMBOLIC=[0|1|2]} \
		{DLL=[0|1|2]} {OBJ=path} {OPT=<WPP command line switches>}

For example to build large model in the debug build use the following 
settings:

		Debug Build:  WMAKE DEBUG=1 TARGET=W MODEL=L SYMBOLIC=1
		Release Build: WMAKE DEBUG=0 TARGET=W MODEL=L


MODEL=[L]
  The "MODEL" argument specifies the ambient memory model.  Only the
  Large memory is supported.

TARGET=[W|R]
  The "TARGET" argument specifies the operating-system on which your
  compiled programs will run.  This may be one of W or R (for
  Windows or Real-mode DOS, respectively).  R should be used only
  for MS-DOS only targets (i.e. command line tools).

DLL=[0|1|2]
  The "DLL" argument specifies whether or not to compile the library
  so that it may subsequently be used for developing a dynamic link
  library (DLL).  The default is DLL=0 (do not include DLL support).
  If DLL=1, MODEL must be L (large).

  The DLL=1 variant is for building your own DLL that contains MFC
  classes and exports a C interface.  This is described in technical note
  TN011 and is known as _USRDLL.
  
  The DLL=2 variant is for building the shared DLL (_AFXDLL).
  This is described in section 2 of this file.

DEBUG=[0|1]
  The "DEBUG" argument specifies whether or not to include diagnostic
  support code for the library.  This may be 0 (for no diagnostics) 
  or 1 (for full diagnostics).

SYMBOLIC=[0|1|2]
  The "SYMBOLIC" argument specifies whether to compile the library with 
  symbolic debugging information or not.  You need to compile the library 
  with symbolic debugging information if you want to trace into MFC code 
  using WD. You should also compile your application files with the -d2 
  option, and link your executable with the debug all linker directive.

  Setting SYMBOLIC does not affect the DEBUG argument, although the
  value of the DEBUG argument does affect the default value of SYMBOLIC
  (discussed below).  A value of 0 indicates that no symbolic debugging
  information is to be compiled into the library.  A value of 1 says
  to compile in full symbolic debugging information for all modules of 
  the library.  A value of 2 compiles symbolic debugging information only 
  into a select set of the most commonly referenced modules (WinMain, 
  diagnostic memory allocator, message map, main message loop, and the 
  application class.)

  The default value depends on the setting of the DEBUG argument.
  If DEBUG=1, SYMBOLIC defaults to 2.  If DEBUG=0, SYMBOLIC also defaults
  to 0.  The installed libraries have been built with SYMBOLIC=1 for
  maximum symbolic debugging information.
  
OBJ=[path]
  We recommend storing .OBJ files in a separate directory so that you
  may compile different versions of the MFC library concurrently.
  The "OBJ" argument allows you to specify where these files are stored
  during the build process.  The directory specified is created and
  removed automatically as required.  This defaults to a combination
  of the target, model, and debug status, preceded by a '_' (i.e. _LWD).

OPT=[switches]
  If your library needs to be built with custom compiler switches, then
  these may be included in the "OPT" argument.  Note that switches need
  to be separated by spaces, so when including more than one extra
  compiler switch, enclose the whole OPT= argument in double-quotes.
  This is an advanced feature; read the Makefile and the details on each
  of the switches concerned in the WATCOM C/C++ Users Guide before using 
  this option.

Defaults
  The default is:
	  wmake MODEL=L TARGET=W DEBUG=1 OBJ=_LWD

Note:  If you wish to use only the non-Windows classes then build
an 'R' (real-mode) library variant. There are three MFC sample applications
that do not require Microsoft Windows, and use the real-mode libraries.
See the WinHelp file MFCSAMP.HLP for details about each sample and
which variant of the library each requires.


============================
 2.  BUILDING THE SHARED DLL
============================

Building the shared DLL is very similar to the static link
variants.  You must, however, use the MFCDLL.MAK file.

To build the shared DLL components that contain the implementation
for OLE 2.0, ODBC and WINSOCK use MFCOLE.MAK, MFCDB.MAK and MFCNET.MAK
respectively.  These additional DLLs are required only if your application 
utilizes the WINSOCK, database or OLE 2.0 classes.

Technical note TN033 explains in detail how to build the shared
DLL and how to build an application that uses the shared DLL.


===============================
 3. AFTER BUILDING THE LIBRARY
===============================

Once the library has been built successfully, you may want to delete
object files with:

  WMAKE CLEAN OBJ=[path]

Note that if you used the "OBJ" argument while building the library,
specify the same sub directory in the cleanup command.

This will remove all of the temporary .OBJ files created by building the
library, and remove the directory where they were stored.

Always perform a cleanup before building a new variant of the library,
or use different object paths for each variant.  Note that the OBJ files
are only necessary during the building process.


======================================
 4. SOURCE CODE FORMATTING CONVENTION
======================================

All MFC source code has been formatted such that leading whitespace
on a line is made up of physical tabs, while embedded whitespace is
physical spaces.  MFC source code assumes that your editor is set to
display a physical tab as four blanks.

For example:

int FormatExample()
{
/*
Statements below should start in column 5 if tabs are set correctly
Comment should start in column 20
12345678901234567890
*/
	int i;
	i = 5;         // whitespace between statement and comment is spaces

	return i;

}
